3.1 区块的基本结构：区块头与区块体

区块的双层容器结构

区块链之所以称为"链"，是因为区块（Block）是它的基本组成单元。每个区块由两层结构构成：

┌─────────────────────────────────────────────┐
│                区块 (Block)                   │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │         区块头 (Block Header)         │    │
│  │  80 字节（比特币）≈ 508 字节（以太坊） │    │
│  │  - 版本号 (4B)                        │    │
│  │  - 前序哈希 (32B)                     │    │
│  │  - 默克尔根 (32B)                     │    │
│  │  - 时间戳 (4B)                        │    │
│  │  - 难度目标 (4B)                      │    │
│  │  - 随机数 (4B)                        │    │
│  └──────────────────────────────────────┘    │
│                                              │
│  ┌──────────────────────────────────────┐    │
│  │         区块体 (Block Body)           │    │
│  │  交易列表 (变长，通常 1K-3K 笔交易)   │    │
│  │  - coinbase 交易（首笔） + 普通交易    │    │
│  └──────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

flowchart LR
    subgraph 区块
        direction TB
        H["区块头<br/>80 字节"] --> F1["版本号 (4B)"]
        H --> F2["前序哈希 (32B)"]
        H --> F3["默克尔根 (32B)"]
        H --> F4["时间戳 (4B)"]
        H --> F5["难度目标 (4B)"]
        H --> F6["随机数 (4B)"]
        B["区块体<br/>交易列表"] --> T1["Coinbase 交易"]
        B --> T2["交易 #1"]
        B --> T3["交易 #2"]
        B --> TN["..."]
    end

为什么将头与体分离？

这是区块链设计中最精妙的工程决策之一。区块头包含所有用于链式链接和共识验证的关键信息。轻节点（如手机钱包的 SPV 客户端）只需同步 80 字节/块的区块头（目前约 80 MB），就能验证最长链和交易包含性，无需下载高达 600+ GB 的完整区块数据。

比特币 vs 以太坊的区块结构差异预告：以太坊的区块头要复杂得多，包含三棵树的根哈希——状态根（State Root）、交易根（Transactions Root）和收据根（Receipts Root），因为以太坊需要维护全局状态（账户余额、合约存储等），而比特币只需验证交易是否被包含。

本节要点

• 每个区块由 80 字节的区块头和变长的区块体组成
• 头体分离使轻节点仅通过区块头即可验证链的正确性
• 以太坊的区块头比比特币更复杂，包含三棵树根

3.2 区块头字段详解

比特币的区块头固定为 80 字节，精确排列为 6 个字段。理解每个字段的技术含义，是理解比特币共识机制的基础。

字段一览

逐字段详解

版本号（4 字节）：指示区块所遵循的协议版本。在 BIP-9 机制下，版本号的高位比特被用作软分叉信号——矿工通过设置特定位表示支持某种协议升级（如 SegWit 的 bit 1）。当 95% 的区块在难度调整周期内设置了该位，升级即被锁定激活。

前序哈希（32 字节）：前一区块头的双重 SHA-256 哈希。这是区块链"链"的本质——每个区块通过这个字段"指向"其父区块，形成一条单向加密链接。

默克尔根（32 字节）：区块内所有交易经过 Merkle 树归约后得到的 32 字节根哈希。它保证了区块体交易集合的完整性：任何人无法在不改变默克尔根的情况下修改任何交易。

时间戳（4 字节）：Unix 时间戳格式（自 1970-01-01 00:00:00 UTC 以来的秒数）。比特币要求区块时间戳必须大于中位数过去 11 个区块的时间戳，且不得超过节点本地时间 +2 小时，以防止矿工通过操纵时间戳获取不公平的挖矿优势。

难度目标（4 字节）：采用压缩编码格式（nBits）。解码公式为：

例如 nBits = 0x1d00ffff 的含义是 exponent = 0x1d = 29，coefficient = 0x00ffff，因此 target = 0x00ffff × 256^(29-3)。区块哈希必须满足：

目标值越小，难度越高（即需要更多前导零）。

随机数（4 字节）：一个 32-bit 无符号整数。矿工通过依次递增 nonce 来尝试不同的区块头，寻找满足 PoW 条件的哈希。由于 32-bit 只有约 42.9 亿个值，在比特币全网算力极高的今天，单个区块可以在不到 1 秒内耗尽所有 nonce。因此矿工还会修改 ExtraNonce（coinbase 交易中的附加字段）或时间戳来获得更大的搜索空间。

区块头原始字节拆解实例

以下是一个比特币测试网上特定区块头的十六进制表示及其字段解码：

import struct
import hashlib

# 示例区块头原始字节（测试网，高度 #100，十六进制）
# 为演示目的构造的近似值
hex_header = (
    "01000000"                      # 版本号 (4B)
    "0000000000000000000000000000000000000000000000000000000000000000"  # 前序哈希 (32B)
    "3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a"  # 默克尔根 (32B)
    "29ab5f49"                      # 时间戳 (4B)
    "ffff001d"                      # 难度目标 (4B)
    "1dac2b7c"                      # 随机数 (4B)
)

raw = bytes.fromhex(hex_header)

version = struct.unpack("<I", raw[0:4])[0]
prev_hash = raw[4:36][::-1].hex()      # 小端序 → 大端序
merkle_root = raw[36:68][::-1].hex()
timestamp = struct.unpack("<I", raw[68:72])[0]
bits = struct.unpack("<I", raw[72:76])[0]
nonce = struct.unpack("<I", raw[76:80])[0]

print(f"版本号:     {version}")
print(f"前序哈希:   {prev_hash}")
print(f"默克尔根:   {merkle_root}")
print(f"时间戳:     {timestamp} ({__import__('datetime').datetime.utcfromtimestamp(timestamp)})")
print(f"难度目标:   0x{bits:08x}")
print(f"随机数:     {nonce}")

# 验证区块哈希
block_hash = hashlib.sha256(hashlib.sha256(raw).digest()).digest()[::-1].hex()
print(f"区块哈希:   {block_hash}")

本节要点

• 比特币区块头固定 80 字节，包含 6 个字段
• nBits 是压缩表示的 256-bit 难度目标，PoW 条件为区块哈希 < target
• Nonce 仅为 32-bit，矿工通过 ExtraNonce 和时间戳扩展搜索空间

3.3 链式结构：哈希指针与防篡改原理

哈希指针的概念

哈希指针（Hash Pointer） 是一种特殊的数据结构：它不仅指向数据的存储位置，还包含该数据的密码学摘要（哈希值）。在比特币中，每个区块头里的前序哈希字段就是一个典型的哈希指针——它"指向"前一个区块的位置（通过区块哈希索引），同时包含前一个区块内容的完整性摘要。

flowchart LR
    subgraph 区块 N
        BH_N["区块头 N"]
        PH_N["前序哈希: (指向 N-1)"]
        HASH_N["→ 区块哈希 H(H(N-1头)∥...)"]
    end
    subgraph 区块 N+1
        BH_N1["区块头 N+1"]
        PH_N1["前序哈希:<br/>H(区块 N 头)"]
        HASH_N1["→ 区块哈希: H(PH_N1∥...)"]
    end
    subgraph 区块 N+2
        BH_N2["区块头 N+2"]
        PH_N2["前序哈希:<br/>H(区块 N+1 头)"]
    end
    HASH_N -.-> PH_N1
    HASH_N1 -.-> PH_N2

篡改代价的数学表达

假设攻击者篡改了区块 $N$ 中的一笔交易（改变区块头默克尔根 → 改变区块头哈希）：

1. 区块 $N$ 的哈希从 $H_N$ 变为 $H_N'$
2. 区块 $N+1$ 的区块头中存储的是 $H_N$（前序哈希），与 $H_N'$ 不匹配
3. 区块 $N+1$ 需要重新挖矿（工作量证明）
4. 区块 $N+2$ 的前序哈希指向旧 $H_{N+1}$，同样需要重新挖矿
5. 如此传递直到链尖

攻击者需要重做的 PoW 总量 = 从第 $N$ 块到当前块的所有难度之和。

flowchart LR
    subgraph 原始链
        BN_A["区块 N<br/>哈希: abc123"]
        BN1_A["区块 N+1<br/>前序: abc123<br/>哈希: def456"]
        BN2_A["区块 N+2<br/>前序: def456<br/>哈希: ghi789"]
    end
    subgraph 篡改后
        BN_B["❌ 区块 N<br/>哈希: xyz999 ⬅️ 篡改"]
        BN1_B["❓ 区块 N+1<br/>前序: abc123 ≠ xyz999<br/>需要重挖！"]
        BN2_B["❓ 区块 N+2<br/>前序: def456<br/>也需要重挖！"]
    end

Merkle 根的双重锁定

即使攻击者能够秘密累积足够的算力来重算整个链的 PoW，还有第二道防线：默克尔根。篡改区块体中的任何交易 → Merkle 根变化 → 区块头变化 → 哈希变化。这意味着攻击者不仅要为每个区块重做 PoW，还必须同时保证替换后的交易集合的 Merkle 根与新区块头匹配。

双重验证维度交叉锁定，使得篡改的工程复杂度成倍增加。

一句话总结

"试图篡改第 N 个区块的攻击者，必须重做从第 N 块到当前块的所有工作量证明，同时还要保证替换交易集合的 Merkle 根匹配——这是一个随着链增长而呈线性增长的工程成本和指数级扩展的经济成本。"

本节要点

• 哈希指针既是索引（指向位置）也是完整性校验（包含哈希摘要）
• 篡改历史区块需要重做从该区块到链尖的所有 PoW
• Merkle 根提供第二层验证，防止仅替换区块头而不替换交易集的攻击

3.4. 默克尔树在交易验证中的核心作用

3.4.1 从哈希列表到默克尔树

在第2.7节中，我们已经接触了默克尔树的基本概念：将若干叶子节点（交易哈希）逐对哈希归约，最终得到一个32字节的根哈希。在第3章区块级别的视角下，默克尔树的角色更加清晰——它是矿工将区块体内所有交易的完整性浓缩为一个32字节值的核心算法。

让我们用一个四笔交易的简单区块来可视化这个过程：

graph TB
    subgraph 区块体
        TX1["tx₁ 哈希"]
        TX2["tx₂ 哈希"]
        TX3["tx₃ 哈希"]
        TX4["tx₄ 哈希"]
    end
    H12["H(tx₁ || tx₂)"]
    H34["H(tx₃ || tx₄)"]
    MerkleRoot["默克尔根<br/>H(H₁₂ || H₃₄)"]
    BlockHeader["区块头<br/>(含默克尔根)"]

    TX1 --> H12
    TX2 --> H12
    TX3 --> H34
    TX4 --> H34
    H12 --> MerkleRoot
    H34 --> MerkleRoot
    MerkleRoot --> BlockHeader

关键洞察：默克尔根是区块体的「数字指纹」。更改区块体中的任何一笔交易——哪怕只改动一个bit——都将导致其叶子哈希变化，进而逐层向上传播，最终改变默克尔根。由于默克尔根被写入区块头，而区块头的哈希又是下一个区块的 prev_hash，任何篡改都将被立即发现，且需要攻击者付出重新挖出所有后续区块的代价。

3.5.1 轻客户端（SPV）验证

默克尔树的另一大价值在于支持简单支付验证（Simple Payment Verification，SPV）。轻客户端无需下载整个区块（容易超过1MB），只需：

1. 同步所有区块头（80字节/块，约60MB/年）
2. 下载待验证交易及其默克尔路径
3. 利用路径哈希向上计算，验证根是否与区块头中的默克尔根一致

验证所需的数据量仅为 O(log₂n) 个哈希，其中 n 是区块中的交易数量。对于一个包含2000笔交易的区块，验证一笔交易仅需11个哈希（约352字节）。

sequenceDiagram
    participant SPV as 轻客户端 (SPV)
    participant FN as 全节点
    SPV->>FN: 请提供区块头链
    FN-->>SPV: 返回区块头(80B/个)
    SPV->>FN: 验证交易tx₃是否在区块#N中
    FN-->>SPV: 返回区块#N头部 + tx₃本身 + Merkle路径([H₄, H₁₂])
    SPV->>SPV: 用tx₃哈希和路径逐层计算Merkle根
    SPV->>SPV: 与区块头中的Merkle根比对
    Note over SPV: ✅ 匹配 → tx₃确实在区块#N中

这里有一个重要的安全边界：SPV能证明「某交易被包含在某个区块中」，但不能证明该区块遵守了协议规则（如没有双花、没有超额发行等）。这就是为什么SPV节点理论上更容易被攻击者欺骗，如果攻击者能创建一个满足难度要求但包含无效交易的「欺诈区块」的话。

3.5.2 篡改演示与不可篡改性的工程本质

我们通过一个思想实验来演示默克尔树的篡改检测能力。

场景：攻击者试图修改区块#100中的一笔交易，将原本支付给Bob的5 BTC改为支付给Eve。

步骤：

• 修改交易数据 → 该交易的哈希值改变
• 叶子节点哈希改变 → 父节点哈希需重算 → 最终默克尔根改变
• 区块头哈希改变（因默克尔根变了） → 无法满足PoW难度目标
• 攻击者必须重新计算该区块的Nonce（重新挖矿）→ 代价约10分钟×全网算力
• 即使成功，区块#101的 prev_hash 指向旧的区块头，必须重新挖区块#101及之后所有区块

这引出一个重要的工程见解：区块链的「不可篡改性」不是物理上的「不能改」，而是经济学上的「改的代价远大于收益」。默克尔树和哈希指针构成了双重保护——前者保护区块内的交易集合，后者保护区块间的顺序完整性。

📌 要点总结

• 默克尔根将区块内所有交易的完整性浓缩为一个32字节的哈希值
• 轻客户端利用默克尔路径实现 O(log₂n) 的交易包含性验证
• 默克尔树 + 哈希指针 = 双重篡改检测机制
• 不可篡改性本质上是经济学约束，而非纯技术约束

3.5. 区块的物理存储与序列化

3.5.1 比特币的双层存储架构

比特币节点并不将「区块」作为一个整体存进数据库。它采用双层存储架构：

flowchart LR
    subgraph 原始数据层
        Blk1["blk00001.dat"]
        Blk2["blk00002.dat"]
        Blk3["blk00003.dat"]
    end
    subgraph 索引层
        LD["LevelDB<br/>chainstate/"]
        IDX["区块索引<br/>(哈希→文件偏移)"]
        UTXO["UTXO集"]
    end
    Blk1 --> IDX
    Blk2 --> IDX
    Blk3 --> IDX
    IDX --> LD
    LD --> UTXO

• 原始数据层（.dat 文件）：区块以追加模式写入 blk*.dat 文件，每128MB自动滚动到下一个文件。一旦写入，永不修改。这是日志式写入（append-only log）的经典实践。
• 索引层（LevelDB）：两个关键键值存储：
• chainstate/：存储当前UTXO集（每个输出是否被花费），用于新交易的输入验证。
• blocks/index/：存储每个区块的哈希到文件偏移量及元数据的映射。

截至2024年前后，比特币主网完整区块数据（blk*.dat）已超过550GB，chainstate索引约8-10GB。以太坊的存档节点（full archival）则普遍超过12TB——这很大程度上是因为以太坊的「世界状态」模型需要保存所有历史状态树的中间节点。

3.5.2 区块的序列化格式解析

比特币区块在网络传输和磁盘存储时，采用小端序（Little-Endian）的序列化格式。我们以一个真实区块的十六进制字节流为例（简化版）：

魔数 (4B)       : D9 B4 BE F9   → 主网标识
区块大小 (4B)    : 00 00 00 02   → 区块体 2 字节？(示例简化)
版本号 (4B)      : 01 00 00 00   → 版本1 (小端序 = 1)
前序哈希 (32B)   : [32字节的SHA256值]
默克尔根 (32B)   : [32字节的Merkle树根]
时间戳 (4B)      : E6 5B 6C 66   → 小端序 0x666C5BE6 = 1717914598 (Unix时间)
难度目标 (4B)     : 1D 00 FF FF   → nBits格式: 指数0x1D, 尾数0x00FFFF
随机数 (4B)      : 12 34 56 78   → Nonce
交易计数 (VarInt) : 01            → 1笔交易 (Coinbase)
交易列表        : [交易序列化数据...]

以下Python代码演示如何用struct模块解析比特币区块头：

import struct
import hashlib

def parse_block_header(header_bytes: bytes) -> dict:
    """解析80字节的比特币区块头"""
    fields = {}
    fields['version'] = struct.unpack('<I', header_bytes[0:4])[0]
    fields['prev_hash'] = header_bytes[4:36][::-1].hex()  # 反转字节序
    fields['merkle_root'] = header_bytes[36:68][::-1].hex()
    fields['timestamp'] = struct.unpack('<I', header_bytes[68:72])[0]
    fields['bits'] = struct.unpack('<I', header_bytes[72:76])[0]
    fields['nonce'] = struct.unpack('<I', header_bytes[76:80])[0]
    # 计算实际双哈希
    hash_hex = hashlib.sha256(hashlib.sha256(header_bytes).digest()).hexdigest()
    fields['block_hash'] = hash_hex  # 注意这里未反转
    return fields

# 示例：构造一个模拟的80字节区块头进行演示
mock_header = (
    b'\x01\x00\x00\x00'  # 版本1
    + b'\x00' * 32        # 前序哈希（创世块用全零）
    + b'\x3b\xa3\xed\xfd\x7a\x7b\x12\xb2\x7a\xc7\x2c\x3e\x67\x76\x8f\x61'
    + b'\x7f\xc8\x1b\xc3\x88\x8a\x51\x32\x3a\x9f\xb8\xaa\x4b\x1e\x5e\x4a'  # 默克尔根
    + struct.pack('<I', 1231006505)  # 时间戳 2009-01-03
    + struct.pack('<I', 0x1d00ffff)  # 难度目标
    + struct.pack('<I', 2083236893)  # Nonce
)

result = parse_block_header(mock_header)
for k, v in result.items():
    print(f"{k:>15}: {v}")

输出示例（数值与比特币创世块参数对应）：

        version: 1
      prev_hash: 0000000000000000000000000000000000000000000000000000000000000000
    merkle_root: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
      timestamp: 1231006505
           bits: 486604799
          nonce: 2083236893
     block_hash: 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

3.5.6 以太坊的MPT存储预告

与比特币不同，以太坊使用 Merkle Patricia Trie（MPT） 来管理账户状态。MPT支持高效的键值寻址（按地址查找余额）和前缀查询（枚举所有账户），而比特币的UTXO集只需要检查「某个输出是否被花费」，是一种更简单的存在性查询。

以太坊的区块头包含三棵树的根哈希：

• 状态树（State Trie）：所有账户（EOA + CA）的余额、Nonce、存储根、代码哈希
• 交易树（Transaction Trie）：区块内所有交易的哈希列表
• 收据树（Receipt Trie）：每笔交易的执行结果（状态码、Gas消耗、日志）

这种设计使以太坊的区块头从比特币的80字节膨胀到约508字节（不含扩展字段），但也赋予了它「世界状态的密码学快照」能力——你可以通过状态树根直接在数学上证明某个时刻某个账户的余额。我们将在第7章深入学习MPT的节点类型与证明机制。

📌 要点总结

• 比特币采用 .dat 文件 + LevelDB 索引的双层存储架构
• 区块序列化使用小端序格式，通过 struct 模块可解析
• 以太坊使用 MPT 管理状态，区块头包含三棵树的根哈希
• 存储架构差异反映了两种区块链的状态模型本质区别

3.6 创世块：一切的起点

3.6.1 什么是创世块？

创世块（Genesis Block）是区块链中高度为0的区块，它没有任何前序区块，prev_hash 字段通常为全零。创世块的完整数据（包括coinbase交易和区块头字段）被硬编码在每个全节点的客户端源代码中。

为什么需要硬编码？ 因为如果没有创世块作为信任锚点，客户端将无法区分自己连接的是真正的比特币网络还是一个完全伪造的冒充链。所有节点在启动时都会验证第一个区块的哈希是否与本地代码中硬编码的值一致——这是信任链的数学起点。

3.6.2 比特币创世块：密码朋克的历史烙印

比特币的创世块诞生于 2009年1月3日，以下是其核心参数：

真正让这个创世块充满传奇色彩的是coinbase交易的数据载荷：

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

这是当天《泰晤士报》的头版头条标题，翻译为「2009年1月3日，英国财政大臣濒临第二次银行救助」。中本聪通过将报纸头版嵌入创世块，实现了两件事：

1. 时间戳证明：区块的创建时间不可能早于2009年1月3日（报纸出版日）
2. 社会隐喻：表达对传统银行体系的不信任是比特币诞生的原动力

值得注意的是，比特币创世块的50 BTC奖励输出使用了一个特殊的脚本，导致该笔资金实际上无法花费（它是比特币网络中唯一一个被「冻结」的UTXO）。

3.6.3 以太坊创世块：预分配与状态初始化

以太坊的创世块没有硬编码在源码中，而是通过一个 genesis.json 配置文件来定义的。以下是以太坊主网的创世参数：

{
  "config": {
    "chainId": 1,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0
  },
  "nonce": "0x0000000000000042",
  "timestamp": "0x00",
  "extraData": "0x" + "以太坊创世块签名",
  "gasLimit": "0x8000000",
  "difficulty": "0x400000000",
  "alloc": {
    "0x0000000000000000000000000000000000000001": {"balance": "1"},
    "0x0000000000000000000000000000000000000002": {"balance": "1"},
    ... (创始销售参与者地址)
  }
}

与比特币的不同之处在于：

• 预分配（Pre-allocation）：以太坊在创世时就将ETH分配给了创始销售参与者、基金会和早期贡献者。比特币没有预分配，所有BTC都是通过挖矿产出的。
• 难度设置：以太坊创世难度较低，使得早期区块可被CPUs快速挖出，促进网络早期启动。
• 数据可读性：以太坊创世块可通过 geth 的 JSON-RPC 直接读取：eth.getBlock(0)。

# 读取比特币创世块
bitcoin-cli getblock $(bitcoin-cli getblockhash 0)

# 读取以太坊创世块（通过geth JSON-RPC）
curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x0",true],"id":1}' \
  http://localhost:8545

3.6.4 跨链创世块对比与启示

创世块不仅仅是一个技术构件，它承载了每条链的历史叙事和哲学底蕴：

• 比特币创世块 = 去中心化货币的社会宣言
• 以太坊创世块 = 可编程价值的启动配置
• 每条链的创世块 = 一切状态演化的数学起点

📌 要点总结

• 创世块是高度为0的区块，没有前序哈希，作为整条链的信任锚点
• 比特币创世块包含《泰晤士报》标题，具有深刻的密码朋克文化隐喻
• 以太坊创世块通过genesis.json定义，包含大量预分配地址
• 创世块是区块链「不可更改」的终极起点——改它等于创建一条新链

3.7. 本章小结：从数学到工程到历史

第3章构建了区块链数据结构的完整认知框架：

flowchart TB
    A["3.1 区块结构<br/>区块头 + 区块体"] --> B["3.2 字段详解<br/>版本/前序哈希/默克尔根/时间戳/难度/Nonce"]
    B --> C["3.3 链式结构<br/>哈希指针 + 防篡改"]
    C --> D["3.4 Merkle树<br/>交易验证核心"]
    D --> E["3.5 物理存储<br/>序列化与LevelDB"]
    E --> F["3.6 创世块<br/>一切的起点"]
    F --> G["🎯 3.7 小结"]
    G --> H["➡️ 第4章: 比特币协议"]
    G --> I["➡️ 第7章: 以太坊架构"]

三个关键认知

1. 区块头是「高度浓缩的信任胶囊」：80字节（比特币）/ 约508字节（以太坊）的紧凑结构中，浓缩了版本、链接、交易摘要、时间证明和工作量证明——全部用于在无需信任的前提下验证区块的有效性。

1. 哈希指针既是索引也是完整性校验：区块间的 prev_hash 将历史串联成不可篡改的链条，区块内的 merkle_root 将交易集合绑定到区块头。两种哈希指针协作，构成了区块链「信任最小化」的底层密码学基石。

1. 创世块是所有状态演化的数学起点：从第0块开始的每一次状态转移都建立在创世块不可更改的初始条件之上。无论区块链最终增长到多大规模，一切都可以追溯到创世块——这是整条链唯一不需要信任的锚点。

衔接预告：理解了区块链的数据结构之后，下一章（第4章）将深入比特币协议，探索UTXO模型如何实现去中心化支付、交易脚本系统如何定义所有权、以及PoW挖矿的完整流程。与此同时，第7章将以太坊作为一个「世界计算机」状态机的架构与第3章所学形成深度对比。